1. Field of the Invention
This invention relates the coupling of state and behavior of an object in a DBMS and in application programs that access the DBMS.
2. Background Art
Existing Database Management Systems (DBMSs) cannot guarantee full coupling of an object's state and behavior in the client environment. In an object-oriented environment, a software application uses a module or entity referred to as an object. An object is comprised of both state and behavior. An object's state is determined by the set of values an object carries for a set of properties or variables. A property can be an attribute of the object or a relation between the object and one or more other objects.
Behavior is defined by the set of operations that can be performed with the object. Each operation is implemented in a routine that is referred to as a method. An object can include a plurality of methods. An operation is performed by invoking one of the object's methods. A method invocation usually occurs as a result of a message sent to an object by another object. The message identifies the method, or operation, that is to be performed. In addition, the message may contain a plurality of properties or arguments that are used by the method.
In the prior art, a DBMS only manages an object's state. Thus, for example, when an application needs an object, it can only retrieve the object's state from the DBMS. The object's method(s) must be retrieved from another source such as a class library, for example.
In addition, the introduction of user-written code in a DBMS engine can compromise the integrity of the engine and is therefore not recommended. To ensure the integrity of the DBMS, a separate implementation of the same object method used by a client is stored in the DBMS server environment. The implementation stored in the DBMS is referred to as a stored procedure. Stored procedure languages are not object-oriented programming languages. A stored procedure is not locally invokable in a client's environment and the DBMS does not use the client's object method. Thus, in the prior art, the same logic is duplicated for different environments. This results in increased development and maintenance costs, and the possibility of serious inconsistencies in object behavior.
As more fully described below, prior art capabilities do not include an ability to store a complete object definition that can be accessed in both a DBMS server and client environment. Object definitions used in these two different environments are effectively stored in separate locations resulting in synchronization issues. In addition, each client application must incorporate all the class libraries that contain any needed functionality. The use of polymorphism (e.g., the ability to refer to different things having different forms) is greatly restricted. Thus, there is added complexity in the management of each client application. This results in additional development and maintenance costs as well as the possibility for inconsistencies.
Relational DBMS
An attribute of an object can be set in a variety of ways. One way is by retrieving information stored in a database management system (DBMS) into a property of the object. A relational DBMS stores information in a table or relation. A table consists of a set of rows and columns. A column defines a field in a row. A row is collection of fields that represents one instance or record of data. The following provides an example of an Employee table for storing employee information:
First Name Middle Name Last Name EmployeeID Salary Manager Level Peter Thomas Smith 345789 $50,000 804356 P4
In this example, the Employee table contains a single row (a table can contain multiple rows, however) that is comprised of seven columns or fields (i.e., First Name, Middle Name, Last Name, EmployeeID, Salary, Manager, and Level). The data stored in the Employee table can be retrieved and used by an application. A data manipulation language (DML) is used to formulate a query to retrieve the data. For example, a query can be used to retrieve the row of the Employee table illustrated above.
In addition to storing application data, the DBMS uses tables to store schema data, or metadata. Metadata contains information that describes the structure of the data stored in the DBMS. For example, metadata identifies the tables contained in the DBMS and the columns in each table. Metadata is defined using a data definition language (DDL).
The metadata may include a Tables relation to define each table in the DBMS. The following provides an example of the Tables relation that contains a record for the Employee table:
 Name Number of Columns Employee 7
In the above example, the Tables relation contains a record for each table in the DBMS. Each record contains two columns: Name and Number of Columns. The Name field identifies the name of a table and the Number of Columns field defines the number of columns in the table defined by the record.
To further illustrate, the metadata may contain a columnName table that identifies all of the columns defined in a table in the DBMS. The following provides an example of an entry in the columnName table for the First Name column in the Employee table:
 Name Table Name Column No. Column Type Length First Name Employee 1 char 20
Each column in a table has a record in the columnName table. Each record in the columnName table has fields that further define the associated column. For example, the columnName table may include Name, Table Name, Column No., Column Type and Length columns or fields. In the above example, the columnName table contains a record that defines the First Name column as the first column in the Employee table and having a length of twenty characters.
Stored Procedures
To implement logic, a relational DBMS uses stored procedures implemented in a special language (e.g., Oracle's PL/SQL) that execute safely in the database server environment and that can be invoked using queries. However, the stored procedures that run in a relational DBMS environment do not provide mechanisms to dynamically distribute the procedures to clients so that they can execute at the client. Thus, the logic implemented by a stored procedure in the DBMS must be duplicated at the client. This duplication requires additional development costs. Further, any modifications or upgrades must be ported to each storage site thereby duplicating development efforts and increasing costs.
Object-Oriented DBMS
Like relational DBMS's, an object-oriented DBMS (OODBMS) stores an object's state on disk. An OODBMS typically uses a library implementation to retrieve an object. An OODBMS stores an object's state on disk and maps it into programming language objects. The state is mapped into the object such that the state can be retrieved from the DBMS and stored in the object's attributes when the object is instantiated. The object's class is defined in a compiled library that includes the object's behavior. The library is linked into the program from compiled libraries (typically written in C++) and used at run time to define the object's behavior. It is up to the database designer to distribute the class libraries to the client systems and keep these libraries up-to-date with the methods and objects stored in the database, if any. A database designer must distribute the class libraries to client systems and ensure that they remain current and synchronized across multiple sites with the state definition contained in the DBMS.
FIG. 2 provides an illustration of object retrieval using an OODBMS. DBMS 200 consists of schema 202 and data 206. DBMS 200 is an OODBMS. Schema 202 comprises the metadata that defines the structure for data 206. Data 206 contains application data such as that stored in the Employee table illustrated above. DBMS 200 does not store both state and behavior information such that the behavior can be retrieved into a client environment. DBMS 200 may encode behavior as stored procedures that execute in the DBMS engine. DBMS 200 stores only state information that can be retrieved into the client environment.
Object 208 includes both state and behavior. However, because DBMS 200 does not store both state and behavior, the state and behavior of object 208 must be retrieved from different sources. DBMS 200 contains state information for object 208. The state information for object 208 is stored in data 206. Library 204 contains the behavior of object 208 as well as a class definition for object 208. When object 208 is instantiated, an instance of its class as defined in library 204 is created. The state of object 208 is then set by retrieving the state information stored in data 206 into properties of object 208.
It is not possible to couple both state and behavior information for an object retrieved into a client from a relational DBMS. This results in the need to obtain an object's definition by accessing multiple sources. The DBMS server and its clients access separate sources to obtain behavior information. This raises synchronization and consistency issues between the DBMS server and the client. The synchronization issue is magnified when multiple clients are accessing different class libraries for the same class definition.
Query Languages
Referring to FIG. 2, DBMS 200 uses a DML to maintain the information stored in data 206. For example, SQL can be used to express select, update, insert and delete operations on tables in a DBMS. The DML primarily used by DBMS's is Structured Query Language (SQL). SQL is used to perform operations on data 206.
A new version of SQL referred to as "SQL3" is currently being defined by the ANSI X3H2 "SQL3" Committee that provides "object-relational" extensions to the existing SQL language. The SQL3 implementations are designed to store object attributes and metadata describing the object types in the database. However, these implementations do not provide the ability to couple behavior with state such that a retrieval operation can yield both state and behavior from the same source using the same operation.